

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>


<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<base target="_top">
<style type="text/css">
  

/* default css */

table {
  font-size: 1em;
  line-height: inherit;
  border-collapse: collapse;
}


tr {
  
  text-align: left;
  
}


div, address, ol, ul, li, option, select {
  margin-top: 0px;
  margin-bottom: 0px;
}

p {
  margin: 0px;
}


pre {
  font-family: Courier New;
  white-space: pre-wrap;
  margin:0;
}

body {
  margin: 6px;
  padding: 0px;
  font-family: Verdana, sans-serif;
  font-size: 10pt;
  background-color: #ffffff;
  color: #000;
}


img {
  -moz-force-broken-image-icon: 1;
}

@media screen {
  html.pageview {
    background-color: #f3f3f3 !important;
    overflow-x: hidden;
    overflow-y: scroll;
  }

  

  body {
    min-height: 1100px;
    
    counter-reset: __goog_page__;
  }
  
  * html body {
    height: 1100px;
  }
  /* Prevent repaint errors when scrolling in Safari. This "Star-7" css hack
     targets Safari 3.1, but not WebKit nightlies and presumably Safari 4.
     That's OK because this bug is fixed in WebKit nightlies/Safari 4 :-). */
  html*#wys_frame::before {
    content: '\A0';
    position: fixed;
    overflow: hidden;
    width: 0;
    height: 0;
    top: 0;
    left: 0;
  }
  
  .pageview body {
    border-top: 1px solid #ccc;
    border-left: 1px solid #ccc;
    border-right: 2px solid #bbb;
    border-bottom: 2px solid #bbb;
    width: 648px !important;
    margin: 15px auto 25px;
    padding: 40px 50px;
  }
  /* IE6 */
  * html {
    overflow-y: scroll;
  }
  * html.pageview body {
    overflow-x: auto;
  }
  

  
    
    .writely-callout-data {
      display: none;
    }
    

    .writely-footnote-marker {
      background-image: url('MISSING');
      background-color: transparent;
      background-repeat: no-repeat;
      width: 7px;
      overflow: hidden;
      height: 16px;
      vertical-align: top;

      
      -moz-user-select: none;
    }
    .editor .writely-footnote-marker {
      cursor: move;
    }
    .writely-footnote-marker-highlight {
      background-position: -15px 0;
      -moz-user-select: text;
    }
    .writely-footnote-hide-selection ::-moz-selection, .writely-footnote-hide-selection::-moz-selection {
      background: transparent;
    }
    .writely-footnote-hide-selection ::selection, .writely-footnote-hide-selection::selection {
      background: transparent;
    }
    .writely-footnote-hide-selection {
      cursor: move;
    }

    /* Comments */
    .writely-comment-yellow {
      background-color: #ffffd7;
    }
    .writely-comment-orange {
      background-color: #ffe3c0;
    }
    .writely-comment-pink {
      background-color: #ffd7ff;
    }
    .writely-comment-green {
      background-color: #d7ffd7;
    }
    .writely-comment-blue {
      background-color: #d7ffff;
    }
    .writely-comment-purple {
      background-color: #eed7ff;
    }

  


  
  .br_fix span+br:not(:-moz-last-node) {
    
    position:relative;
    
    left: -1ex
    
  }

  
  #cb-p-tgt {
    font-size: 8pt;
    padding: .4em;
    background-color: #ddd;
    color: #333;
  }
  #cb-p-tgt-can {
    text-decoration: underline;
    color: #36c;
    font-weight: bold;
    margin-left: 2em;
  }
  #cb-p-tgt .spin {
    width: 16px;
    height: 16px;
    background: url(//ssl.gstatic.com/docs/clipboard/spin_16o.gif) no-repeat;
  }
}

h6 { font-size: 8pt }
h5 { font-size: 8pt }
h4 { font-size: 10pt }
h3 { font-size: 12pt }
h2 { font-size: 14pt }
h1 { font-size: 18pt }

blockquote {padding: 10px; border: 1px #DDD dashed }

.webkit-indent-blockquote { border: none; }

a img {border: 0}

.pb {
  border-width: 0;
  page-break-after: always;
  /* We don't want this to be resizeable, so enforce a width and height
     using !important */
  height: 1px !important;
  width: 100% !important;
}

.editor .pb {
  border-top: 1px dashed #C0C0C0;
  border-bottom: 1px dashed #C0C0C0;
}

div.google_header, div.google_footer {
  position: relative;
  margin-top: 1em;
  margin-bottom: 1em;
}


/* Table of contents */
.editor div.writely-toc {
  background-color: #f3f3f3;
  border: 1px solid #ccc;
}
.writely-toc > ol {
  padding-left: 3em;
  font-weight: bold;
}
ol.writely-toc-subheading {
  padding-left: 1em;
  font-weight: normal;
}
/* IE6 only */
* html writely-toc ol {
  list-style-position: inside;
}
.writely-toc-none {
  list-style-type: none;
}
.writely-toc-decimal {
  list-style-type: decimal;
}
.writely-toc-upper-alpha {
  list-style-type: upper-alpha;
}
.writely-toc-lower-alpha {
  list-style-type: lower-alpha;
}
.writely-toc-upper-roman {
  list-style-type: upper-roman;
}
.writely-toc-lower-roman {
  list-style-type: lower-roman;
}
.writely-toc-disc {
  list-style-type: disc;
}

/* Ordered lists converted to numbered lists can preserve ordered types, and
   vice versa. This is confusing, so disallow it */
ul[type="i"], ul[type="I"], ul[type="1"], ul[type="a"], ul[type="A"] {
  list-style-type: disc;
}

ol[type="disc"], ol[type="circle"], ol[type="square"] {
  list-style-type: decimal;
}

/* end default css */


  /* default print css */
  @media print {
    body {
      padding: 0;
      margin: 0;
    }

    div.google_header, div.google_footer {
      display: block;
      min-height: 0;
      border: none;
    }

    div.google_header {
      flow: static(header);
    }

    /* used to insert page numbers */
    div.google_header::before, div.google_footer::before {
      position: absolute;
      top: 0;
    }

    div.google_footer {
      flow: static(footer);
    }

    /* always consider this element at the start of the doc */
    div#google_footer {
      flow: static(footer, start);
    }

    span.google_pagenumber {
      content: counter(page);
    }

    span.google_pagecount {
      content: counter(pages);
    }

    .endnotes {
      page: endnote;
    }

    /* MLA specifies that endnotes title should be 1" margin from the top of the page. */
    @page endnote {
      margin-top: 1in;
    }

    callout.google_footnote {
      
      display: prince-footnote;
      footnote-style-position: inside;
      /* These styles keep the footnote from taking on the style of the text
         surrounding the footnote marker. They can be overridden in the
         document CSS. */
      color: #000;
      font-family: Verdana;
      font-size: 10.0pt;
      font-weight: normal;
    }

    /* Table of contents */
    #WritelyTableOfContents a::after {
      content: leader('.') target-counter(attr(href), page);
    }

    #WritelyTableOfContents a {
      text-decoration: none;
      color: black;
    }

    /* Comments */
    .writely-comment-yellow {
      background-color: #ffffd7;
    }
    .writely-comment-orange {
      background-color: #ffe3c0;
    }
    .writely-comment-pink {
      background-color: #ffd7ff;
    }
    .writely-comment-green {
      background-color: #d7ffd7;
    }
    .writely-comment-blue {
      background-color: #d7ffff;
    }
    .writely-comment-purple {
      background-color: #eed7ff;
    }
  }

  @page {
    @top {
      content: flow(header);
    }
    @bottom {
      content: flow(footer);
    }
    @footnotes {
      border-top: solid black thin;
      padding-top: 8pt;
    }
  }
  /* end default print css */


/* custom css */


/* end custom css */

/* ui edited css */

body {
  font-family: Verdana;
  
  font-size: 10.0pt;
  line-height: normal;
  background-color: #ffffff;
}
/* end ui edited css */


/* editor CSS */
.editor a:visited {color: #551A8B}
.editor table.zeroBorder {border: 1px dotted gray}
.editor table.zeroBorder td {border: 1px dotted gray}
.editor table.zeroBorder th {border: 1px dotted gray}


.editor div.google_header, .editor div.google_footer {
  border: 2px #DDDDDD dashed;
  position: static;
  width: 100%;
  min-height: 2em;
}

.editor .misspell {background-color: yellow}

.editor .writely-comment {
  font-size: 9pt;
  line-height: 1.4;
  padding: 1px;
  border: 1px dashed #C0C0C0
}


/* end editor CSS */

</style>

  
  <title>W1 Wstęp</title>

</head>

<body 
    
    >
    
    
    
<div id=xfgz style=TEXT-ALIGN:left>
  <b style=COLOR:#3d85c6><font size=5>Wprowadzenie </font></b><br>
  <hr size=2><br>
  <br>
  <b style=COLOR:#3d85c6><font size=3>Rozwój technologiczny</font></b><br>
  <hr size=2><br>
  <div id=fuj1 style=TEXT-ALIGN:left>
    <img src="images/dcjpvv6n_2213f66fsqg5_b.png" style=HEIGHT:341px;WIDTH:500px><br>
    <br>
    <p>
      Systemy komputerowe rozwijane są od roku 1945. Niestety do czasu wynalezienia minikomputerów ich ceny były bardzo wysokie. Sytuację zmieniły mikroprocesory 8-, 16-, 32- i w końcu 64-bitowe, charakteryzujące się dużą mocą obliczeniową, często przewyższającą moc dostępnych wcześniej komputerów.<br>
    </p>
    <p>
      <br>
    </p>
    <p>
      Rozwój systemów komputerowych był rzeczywiście oszałamiający, powodując wzrost współczynnika cena/efektywność o 12 rzędów wielkości.<br>
    </p>
    <p>
      <br>
    </p>
    <p>
      Drugim osiągnięciem, które przyczyniło się do zaistnienia i rozwoju systemów rozproszonych były sieci komputerowe, zarówno lokalne (LAN – ang. <i>Local-Area</i> <i>Networks</i> ), jak i rozległe (WAN – ang. <i>Wide-Area</i> <i>Networks</i> ). Szybkości przesyłanych danych wahają się od kilkudziesięciu Kb/s (kilobitów na sekundę) do dziesiątek Gb/s.
    </p>
    <br>
    <br>
    <b style=COLOR:#3d85c6><font size=3>Definicja systemu rozproszonego</font></b><br>
    <hr size=2><br>
    <div id=gi2l style=TEXT-ALIGN:left>
      <img src="images/dcjpvv6n_2214fh6jd4fj_b.png" style=HEIGHT:341px;WIDTH:500px><br>
      <br>
      Nie istnieje jedna, ogólnie przyjęta definicja systemu rozproszonego. Powodem tego jest między innymi różnorodność aspektów, w jakich systemy te są rozpatrywane. Powyższa definicja zwraca uwagę na integralność systemu rozproszonego, sprawiającego na użytkowniku końcowym wrażenie pracy z systemem scentralizowanym. Jest to własność wysoce pożądana ze względu na złożoność systemów rozproszonych.<br>
      <a href=http://wazniak.mimuw.edu.pl/index.php?title=Sr-1-wyk-1.0-Slajd2 title=Sr-1-wyk-1.0-Slajd2> </a><br>
      <br>
      <b style=COLOR:#3d85c6><font size=3>Cechy systemów rozproszonych</font></b><br>
      <hr size=2><br>
      <div id=nx.: style=TEXT-ALIGN:left>
        <img src="images/dcjpvv6n_2215f3st9vd7_b.png" style=HEIGHT:341px;WIDTH:500px><br>
        <br>
        Uzyskanie spójnego i zwartego obrazu systemu rozproszonego wymaga ukrycia przed użytkownikami wielu szczegółów związanych z jego organizacją. Oznacza to, że różnice pomiędzy komputerami (m.in. architektura komputera, lokalny system operacyjny), różne sposoby komunikowania się komputerów (technologie komunikacyjne, protokoły sieciowe) oraz organizacja systemu rozproszonego są (lub powinny być) niewidoczne dla użytkownika końcowego. Ujednolicenie takie daje w efekcie możliwość korzystania z zasobów systemu w jednolity sposób, korzystając z tego samego interfejsu, niezależnie od czasu i miejsca dokonywanej interakcji.
        <p>
          <br>
        </p>
        <p>
          Kolejna cecha systemów rozproszonych to łatwość ich rozszerzania, co w konsekwencji powinno prowadzić do zapewnienia skalowalności systemu. Łatwość ta jest efektem niezależności komputerów, przy jednoczesnym ukrywaniu szczegółów dotyczących funkcji pełnionych przez poszczególne komputery w systemie. Ze względu na powielanie pewnych funkcji przez wiele komputerów, system rozproszony może sprawiać wrażenie nieustannej dostępności jego zasobów i usług. Dzieje się tak pomimo przejściowych awarii poszczególnych jego komponentów, które są jednak maskowane przejęciem obsługi przez inne komputery. Podobnie dodanie nowych komputerów i/lub użytkowników pozostaje niezauważone przez dotychczasowych użytkowników.
        </p>
        <br>
        <br>
        <b style=COLOR:#3d85c6><font size=3>Architektura systemu rozproszonego</font></b><br>
        <hr size=2><br>
        <div id=es9b style=TEXT-ALIGN:left>
          <img src="images/dcjpvv6n_2216fq8pstgf_b.png" style=HEIGHT:340px;WIDTH:500px><br>
          <br>
          Wrażenie jednolitości systemu można uzyskać poprzez zastosowanie architektury warstwowej w odniesieniu do oprogramowania. System taki bazuje na lokalnych systemach operacyjnych i nadbudowuje warstwę pośrednią (ang. <i>middleware</i> ), dostarczającą ujednoliconego interfejsu dostępu do usług dla aplikacji rozproszonych.<br>
          <br>
          <br>
          <b style=COLOR:#3d85c6><font size=3>Cele systemów rozproszonych</font></b><br>
          <hr size=2><br>
          <div id=g-ey style=TEXT-ALIGN:left>
            <div id=jf_b style=TEXT-ALIGN:left>
              <img src="images/dcjpvv6n_2218hdmcfkz2_b.png" style=HEIGHT:339px;WIDTH:500px><br>
              <br>
              Systemy rozproszone są tworzone ze względu na istotne <i>potencjalne</i> zalety tych systemów. Efektywne zagospodarowanie tych zalet może sprawić, że będą one bardziej atrakcyjne dla użytkownika końcowego niż systemy scentralizowane.<br>
              <br>
              <br>
              <b style=COLOR:#3d85c6><font size=3>Łączenie użytkowników i zasobów</font></b><br>
              <hr size=2><br>
              <div id=s0y5 style=TEXT-ALIGN:left>
                <img src="images/dcjpvv6n_2219c3q8tqdj_b.png" style=HEIGHT:339px;WIDTH:500px><br>
                <br>
                Systemy rozproszone powstają po to, by ułatwić użytkownikom dostęp do zdalnych zasobów, ukrywając fakt ich rozproszenia i umożliwiając współdzielenie. Pojęcie zasób powinno tu być rozumiane szeroko: począwszy od urządzeń (drukarki, skanery), a skończywszy na plikach, stronach WWW. Współdzielony dostęp do zasobów jest uzasadniony głównie ekonomicznie: wiele zasobów jest drogich, zarówno w zakupie jak i w późniejszym utrzymaniu. Korzystanie ze wspólnych zasobów daje też możliwość szybkiej wymiany informacji pomiędzy samymi użytkownikami.<br>
                <br>
                <p>
                  Łatwy dostęp do zasobów nie powinien jednak oznaczać rezygnacji z zapewniania bezpieczeństwa realizowanych operacji. Dotyczy to zarówno poufności, spójności przesyłanych danych, jak i niezaprzeczalności. Problemy bezpieczeństwa ujawniają się również w kontekście samej komunikacji. Monitorowanie aktywności użytkowników i budowanie profili zachowań również może naruszać naszą prywatność.
                </p>
                <br>
                <br>
                <b style=COLOR:#3d85c6><font size=3>Przezroczystość</font></b><br>
                <hr size=2><br>
                <div id=awup style=TEXT-ALIGN:left>
                  <img src="images/dcjpvv6n_2220dcs42kx5_b.png" style=HEIGHT:341px;WIDTH:500px>
                </div>
                <br>
                Rozproszenie zasobów i procesów na fizycznie rozłącznych maszynach może być maskowane tak, aby system był postrzegany jako jedna spójna całość. Mówimy o takim systemie, że jest <i>transparentny</i> . Przezroczystość może być jednak postrzegana na różnych poziomach, a poziomy te mogą być mniej lub bardziej istotne dla użytkownika końcowego. Poniżej przedstawiono podstawowe poziomy przezroczystości rozpatrywane w systemach rozproszonych:
                <p>
                  <br>
                </p>
                <p>
                  <b>Przezroczystość</b> <b>dostępu</b> oznacza ujednolicenie metod dostępu do danych i ukrywanie różnic w reprezentacji danych. Użytkownik korzysta cały czas z tego samego interfejsu dostępu do danych. Różnice w reprezentacji danych mogą wynikać z zastosowania różnych architektur komputerowych. Przykładem jest reprezentacja liczb --- procesory Intela stosują tzw. kodowanie <i>little</i> <i>endian</i> a np. procesory Sun SPARC stosują kodowanie <i>big</i> <i>endian</i> . Różnica polega na kolejności ułożenia poszczególnych bajtów liczby w pamięci.Innym przykładem różnic w reprezentacji danych są różne konwencje nazewnictwa plików stosowane w różnych systemach operacyjnych.
                </p>
                <br>
                <br>
              </div>
              <div id=c7_g style=TEXT-ALIGN:left>
                <img src="images/dcjpvv6n_2221g4w5p7gh_b.png" style=HEIGHT:340px;WIDTH:500px>
              </div>
              <br>
              <b>Przezroczystość</b> <b>położenia</b> oznacza, że użytkownicy nie mogą określić fizycznego położenia zasobu (np. na podstawie jego nazwy czy identyfikatora). Warunkiem koniecznym osiągnięcia przezroczystości położenia jest stosowanie nazewnictwa zasobów, które abstrahuje od ich położenia. Z tego między innymi powodu adresy dokumentów w usłudze WWW zaczęto określać nie jako adresy URL (ang. <i>Universal</i> <i>Resource</i> <i>Locator</i> --- uniwersalny lokalizator zasobów) a raczej jako adresy URI (ang. <i>Universal</i> <i>Resource</i> <i>Identifier</i> --- uniwersalny identyfikator zasobów). Zaakcentowano w ten sposób bardziej ogólny sposób interpretacji elementów składowych adresu. Np. adres: <i>http</i> <i>://</i> <i>www.put.poznan.pl/rekrutacja/rekrutacja.html</i> może być interpretowany jako wskazanie na dokument znajdujący się na serwerze <i>www.put.poznan.pl</i> (URL) lub po prostu całościowo jako identyfikator dokumentu (URI).<br>
              <br>
              <p>
                <b>Przezroczystość</b> <b>wędrówki</b> oznacza, że zasoby mogą być przenoszone pomiędzy serwerami bez potrzeby zmiany sposobu odwoływania się do nich. Uzyskanie przezroczystości wędrówki zakłada oczywiście przezroczystość położenia, gdyż w przeciwnym wypadku po dokonaniu przeniesienia zasobu jego stary identyfikator stawałby się nieaktualny.<br>
              </p>
              <p>
                <br>
              </p>
              <p>
                <b>Przezroczystość</b> <b>przemieszczania</b> oznacza, że zasoby mogą być przenoszone nawet wtedy gdy są używane przez użytkowników i nie wymaga to informowania użytkowników o zmianie położenia. Z taką sytuacją mamy do czynienia np. w przypadku sieci komórkowych, gdzie użytkownicy pomimo fizycznego przemieszczania się mogą prowadzić stale rozmowę (jest to tzw. <i>roaming</i> ).
              </p>
              <br>
              <br>
            </div>
            <div id=cax7 style=TEXT-ALIGN:left>
              <img src="images/dcjpvv6n_222273gfm2fh_b.png" style=HEIGHT:341px;WIDTH:500px><br>
              <br>
              W systemach rozproszonych zwielokrotnianie (replikacja) jest jednym z podstawowych mechanizmów pozwalających na zwiększenie wydajności i niezawodności takich systemów. Stosowanie zwielokrotniania może skutkować jednak znacznymi utrudnieniami dla użytkowników końcowych, wynikającymi m.in. z niespójności współbieżnie modyfikowanych kopii.<br>
              <br>
              <p>
                <b>Przezroczystość</b> <b>zwielokrotniania</b> oznacza, że pomimo zwielokrotniania zasobów użytkownicy nie zauważają tego faktu — korzystają z zasobów dokładnie w taki sam sposób jak w systemie nie stosującym zwielokrotniania. W praktyce oznacza to, że przezroczystość zwielokrotniania można uzyskać w systemach gwarantujących przezroczystość położenia, ponieważ dostęp do każdej z kopii zasobu powinien być realizowany z wykorzystaniem tego samego identyfikatora.<br>
              </p>
              <p>
                <br>
              </p>
              <p>
                System rozproszony umożliwia współdzielenie zasobów. Współdzielenie takie może być realizowane w sposób <i>kooperatywny</i> – jak to ma miejsce np. w przypadku komunikacji – lub w sposób <i>rywalizacyjny</i> , kiedy wielu użytkowników jednocześnie ubiega się o dostęp do tego samego zasobu.<br>
              </p>
              <p>
                <br>
              </p>
              <p>
                <b>Przezroczystość</b> <b>współbieżności</b> gwarantuje, że współbieżne odwoływanie się do tego samego zasobu realizowane przez wielu użytkowników nie będzie prowadziło do powstania stanu niespójnego w systemie. Stan spójny można osiągnąć poprzez blokowanie dostępu do wspólnych danych (gwarantujące wyłączny dostęp) lub poprzez zastosowanie mechanizmu przetwarzania transakcyjnego, które jednak jest trudne do zrealizowania w systemie rozproszonym.
              </p>
              <br>
              <br>
              <div id=dw-6 style=TEXT-ALIGN:left>
                <img src="images/dcjpvv6n_2223wxv6v3gf_b.png" style=HEIGHT:341px;WIDTH:500px><br>
                <br>
                System jako całość powinien działać nawet w przypadku awarii pojedynczych jego komponentów.<br>
                <br>
                <p>
                  <b>Przezroczystość</b> <b>awarii</b> oznacza, że użytkownik nie zauważa faktu uszkodzenia pojedynczych węzłów. Wadliwy komponent powinien zostać zastąpiony poprawnym, a cała operacja nie powinna wpływać na spsób korzystania z systemu. Maskowanie awarii jest zadaniem trudnym, a przy przyjęciu pewnych założeń, nawet niemożliwym. Główna trudność polega na odróżnieniu awarii zdalnego węzła od awarii łączy komunikacyjnych.<br>
                </p>
                <p>
                  <br>
                </p>
                <p>
                  <b>Przezroczystość</b> <b>trwałości</b> ukrywa mechanizmy zarządzania zdalnymi zasobami. Przykładem mogą tu być zdalne obiekty, na rzecz których użytkownicy wywołują metody. Obiekt powinien trwale przechować swój stan po zdalnym wywołaniu jego metody. Z drugiej strony odwołanie do tego obiektu powinno być możliwe nawet wtedy, gdy nie jest przechowywany aktualnie w pamięci.<br>
                </p>
                <p>
                  <br>
                </p>
                <p>
                  Oczekuje się, że systemy rozproszone będą ukrywać przed użytkownikiem szczegóły swojej wewnętrznej organizacji, jednakże osiągnięcie wysokiego poziomu przezroczystości wiąże się z dużymi kosztami, głównie związanymi z ogólną wydajnością systemu. W praktyce dąży się do osiągnięcia racjonalnego kompromisu pomiędzy obserwowaną przez użytkownika złożonością systemu, a efektywnością jego pracy.
                </p>
                <br>
                <br>
                <font color=#3d85c6 size=3><b>Otwartość systemów rozproszonych</b></font><br>
                <hr size=2><br>
                <div id=hzaf style=TEXT-ALIGN:left>
                  <img src="images/dcjpvv6n_2224gc375fff_b.png" style=HEIGHT:340px;WIDTH:500px><br>
                  <br>
                  Systemy rozproszone, aby mogły być rozbudowywane, muszą być <b>otwarte</b> . Oznacza to konieczność standaryzacji stosowanych protokołów i interfejsów komunikacyjnych. Definicje interfejsów obejmują najczęściej opisz składnię usług (nazwy funkcji, typy parametrów i zwracanych wyników). Semantyka usług opisywana jest najczęściej w sposób nieformalny, korzystając z języka naturalnego.<br>
                  <br>
                  <p>
                    Specyfikacja interfejsu aby mogła być implementowana niezależnie przez wielu dostawców oprogramowania musi być <b>zupełna</b> (kompletna) i <b>neutralna</b> . Kompletność oznacza, że opis jest wystarczający do stworzenia implementacji. Neutralność oznacza, że specyfikacja nie narzuca żadnych szczegółów dotyczących implementacji. Spełnienie tych warunków jest konieczne dla osiągnięcia <b>zdolności</b> <b>do</b> <b>współdziałania</b> (ang. <i>interoperability</i> ), która oznacza możliwość współpracy ze sobą komponentów programowych pochodzących od różnych dostawców o ile implementują one odpowiednie interfejsy programowe.<br>
                  </p>
                  <p>
                    <br>
                  </p>
                  <p>
                    <b>Przenośność</b> (ang. <i>portability</i> ) oznacza możliwość uruchomienia aplikacji stworzonej dla jednego systemu w innym systemie bez konieczności wprowadzania jakichkolwiek modyfikacji.
                  </p>
                  <br>
                  <br>
                  <b style=COLOR:#3d85c6><font size=3>Systemy elastyczne</font></b><br>
                  <hr size=2><br>
                  <div id=w3en style=TEXT-ALIGN:left>
                    <img src="images/dcjpvv6n_2225g3srrkf9_b.png" style=HEIGHT:340px;WIDTH:500px>
                  </div>
                  <br>
                  <a href=http://wazniak.mimuw.edu.pl/index.php?title=Sr-1-wyk-1.0-Slajd11 title=Sr-1-wyk-1.0-Slajd11> </a>
                </div>
              </div>
              Dobrze zaprojektowany system otwarty powinien być <b>elastyczny</b> , co w praktyce oznacza łatwość budowy i przebudowy systemu składającego się z komponentów pochodzących od różnych dostawców. Osiągnięcie wysokiej elastyczności jest możliwe poprzez podział systemu rozproszonego na wysoce autonomiczne komponenty komunikujące się poprzez precyzyjnie opisane interfejsy. Daje to możliwość wymiany poszczególnych komponentów bez konieczności wyłączania całego systemu.<br>
              <br>
              <p>
                Otwartość i elastyczność systemów rozproszonych może być wspierana poprzez oddzielenie polityki od mechanizmu. Polityka określa deklaratywnie cele, które chce osiągnąć użytkownik, a mechanizm dostarcza narzędzi do osiągania tych celów. Przykładem może być stosowanie pamięci podręcznych w przeglądarkach internetowych. Jest to mechanizm zwiększający dostępność zasobów w usłudze WWW. Ważne jednakże są tu parametry wejściowe sterujące pracą tej pamięci (czas przechowywania dokumentów, strategia aktualizacji, wybór dokumentów). Parametry te określają właśnie politykę jaką chce się narzucić użytkownik i która może być potencjalnie realizowana z wykorzystaniem innego mechanizmu.
              </p>
              <br>
              <br>
              <b style=COLOR:#3d85c6><font size=3>Skalowanie</font></b><br>
              <hr size=2><br>
              <div id=y29l style=TEXT-ALIGN:left>
                <img src="images/dcjpvv6n_2226ddd7f7dj_b.png" style=HEIGHT:339px;WIDTH:500px><br>
                <br>
                Rozwój sieci komputerowych i liczba komputerów przyłączanych do Internetu wzrastają tak szybko, że jednym z najważniejszych celów projektowych staje się obecnie zapewnienie skalowalności. Skalowalność może być rozważana w trzech różnych wymiarach. Po pierwsze skalowalność pod względem <b>rozmiaru</b> , oznaczająca możliwość dodawania do systemu nowych użytkowników i zasobów. Po drugie skalowalność <b>geograficzna</b> , umożliwiająca rozrzucenie poszczególnych użytkowników po całym świecie. Po trzecie w końcu skalowalność pod względem <b>administracyjnym</b> oznacza, że zarządzanie systemem pozostaje równie proste pomimo zwiększania jego rozmiaru i pomimo dystrybucji odpowiedzialności na wiele jednostek administracyjnych.<br>
                <br>
                <p>
                  Skalowalność pod względem rozmiaru może być ograniczona poprzez stosowanie rozwiązań scentralizowanych. Każdy serwer, który jest jedynym pełniącym określoną funkcję, staje się wąskim gardłem w warunkach wzrastającej liczby żądań. Stosowanie przetwarzania scentralizowanego staje się niekiedy jednak nieuniknione. Przykładem może być przechowywanie poufnych danych, których powielenie powodowałoby zwiększenie ryzyka ich ujawnienia (centralizacja danych). Z centralizacją usług mamy do czynienia wtedy, gdy przetwarzanie zleceń jest realizowane przez pojedynczy serwer. Dobrym przykładem usługi, która jest doskonale zdecentralizowana jest usługa DNS (ang. <i>Domain</i> <i>Name</i> <i>Service</i> ), zajmująca się m.in. odwzorowaniami nazw domenowych na adresy IP. W usłudze tej grupa rozproszonych serwerów realizuje wspólnie wspomnianą funkcję. Rozproszenie przetwarzania jest tu koniecznością, ponieważ liczba żądań przychodzących do systemu jest tak duża, że żaden serwer nie byłby w stanie jej obsłużyć.<br>
                </p>
                <p>
                  <br>
                </p>
                <p>
                  Wysoką skalowalność systemów można osiągnąć poprzez zastosowanie algorytmów zdecentralizowanych. Charakteryzują się one następującymi własnościami:<br>
                </p>
                <p>
                  <br>
                </p>
                <ol>
                  <li>
                    Żadna z maszyn nie posiada pełnej informacji o stanie systemu.
                  </li>
                  <li>
                    Decyzje podejmowane są tylko na podstawie informacji lokalnych.
                  </li>
                  <li>
                    Uszkodzenie pojedynczych maszyn nie powoduje blokady całego systemu.
                  </li>
                  <li>
                    Nie ma niejawnych założeń dot. globalnego zegara.
                  </li>
                </ol>
                <br>
                <p>
                  Ostatnie założenie jest konsekwencją ogólnie przyjętej charakterystyki systemów rozproszonych, w których komunikacja ma charakter <i>asynchroniczny</i> . Oznacza to, że komunikaty docierają do odbiorcy w czasie skończonym, ale bliżej nieokreślonym. Konsekwencją tego założenia jest niemożliwość dokładnego zsynchronizowania lokalnych zegarów komputerów pracujących w sieci (przede wszystkim w sieci rozległej).<br>
                </p>
                <p>
                  <br>
                </p>
                <p>
                  Skalowalność geograficzna jest ograniczana głównie przez dostępne mechanizmy komunikacyjne, które wprowadzają znaczne opóźnienia i charakteryzują się wysoką zawodnością. Opóźnienia powodują, że akceptowalne w sieciach lokalnych przetwarzanie <i>synchroniczne</i> staje się nieakceptowalne w sieciach rozległych, gdyż wprowadza zbyt duże przestoje.
                </p>
                <br>
                <br>
                <b style=COLOR:#3d85c6><font size=3>Metody zapewniania skalowalności</font></b><br>
                <hr size=2><br>
              </div>
              <div id=vrp_ style=TEXT-ALIGN:left>
                <img src="images/dcjpvv6n_2227cxscmwfq_b.png" style=HEIGHT:340px;WIDTH:500px><br>
                <br>
                Systemy rozproszone budowane są z pojedynczych komputerów połączonych siecią. Z punktu widzenia programisty nie jest obojętne jaka jest budowa pojedynczych maszyn w systemie rozproszonym, gdyż rzutuje to na sposób programowania takich systemów. Generalnie można wyróżnić dwie klasy systemów komputerowych: wieloprocesory i multikomputery. Zasadnicza różnica polega na innej organizacji dostępu do pamięci. W wieloprocesorach wszystkie procesory mają dostęp do jednej, wspólnej przestrzeni adresowej. W multikomputerach każda jednostka ma swoją lokalną pamięć.<br>
                <br>
                <p>
                  Drugim ważnym parametrem wyznaczającym charakter systemu rozproszonego jest architektura połączeń pomiędzy poszczególnymi węzłami. Połączenia mogą być realizowane poprzez centralną szynę lub w technologii przełączanej. Połączenia szynowe w wieloprocesorach ułatwiają zarządzanie spójnością danych, ale z drugiej strony bardzo ograniczają skalowalność; szyna przy niedużej liczbie procesorów staje się wąskim gardłem. Często stosowanym rozwiązaniem w takim przypadku jest zastosowanie pamięci podręcznych. Algorytmy wymiany zawartości pamięci podręcznej pozwalają na uzyskiwanie wysokich <i>współczynników</i> <i>trafień</i> (ang. <i>hit</i> <i>rate</i> ), co pozwala na znaczne ograniczenie częstotliwości odwołań do głównej szyny. Z drugiej jednak strony stosowanie pamięci podręcznej powoduje powstawanie problemu spójności kopii tych samych danych przechowywanych na różnych węzłach.
                </p>
                <br>
                <br>
                <b style=COLOR:#3d85c6><font size=3>Homogeniczne systemy multikomputerowe</font></b><br>
                <hr size=2><br>
              </div>
              <div id=s08y style=TEXT-ALIGN:left>
                <img src="images/dcjpvv6n_2228ngg933ff_b.png" style=HEIGHT:340px;WIDTH:500px><br>
                <br>
                Wieloprocesory budowane są poprzez połączenie wielu autonomicznych komputerów siecią. Jeżeli wykorzystywane są komputery o tej samej architekturze, to mamy do czynienia z siecią systemową. Połączenia mogą być również realizowane w architekturze szynowej lub przełączanej. W przypadku architektury przełączanej stosuje się <i>wyznaczanie</i> <i>tras</i> (<i>trasowanie</i> ) komunikatów przez sieć połączeń. Dwie najpopularniejsze topologie połączeń pomiędzy węzłami to siatki i hiperkostki (zobacz następny slajd). Kraty, ponieważ są dwuwymiarowe, są łatwiejsze do implementacji na płaskiej płytce obwodu drukowanego. Hiperkostka jest sześcianem <i>n-wymiarowym</i> . Przykład z następnego slajdu pokazuje kostkę 4-wymiarową.<br>
                <br>
                <p>
                  Praktyczne realizacje koncepcji multikomputera korzystają bądź ze specjalizowanej (często opatentowanej) sieci połączeń, bądź ze standardowych rozwiązań stosowanych w sieciach komputerowych (np. technologia Ethernet). Pierwsze podejście, oczywiście dużo droższe, stosowane jest w komputerach o masywnej równoległości. Multikomputery bazujące na standardowych technologiach zwane są z kolei gronami, grupami stacji roboczych lub po prostu klastrami.
                </p>
                <br>
                <br>
                <b style=COLOR:#3d85c6><font size=3>Architektury połączeń multikomputera</font></b><br>
                <hr size=2><br>
                <div id=m56d style=TEXT-ALIGN:left>
                  <img src="images/dcjpvv6n_2229htqvj6dt_b.png" style=HEIGHT:341px;WIDTH:500px><br>
                  <br>
                  <br>
                  <b style=COLOR:#3d85c6><font size=3>Oprogramowanie dla syst.&nbsp; rozproszonych</font></b><br>
                  <hr size=2>
                </div>
                <br>
              </div>
              <div id=f386 style=TEXT-ALIGN:left>
                <img src="images/dcjpvv6n_2230cn6mrvcn_b.png" style=HEIGHT:340px;WIDTH:500px>
              </div>
            </div>
            <br>
          </div>
          Zadania systemu operacyjnego dla systemu rozproszonego są podobne do zadań klasycznego systemu operacyjnego i w dużej mierze sprowadzają się do zarządzania zasobami (ang. <i>resource</i> <i>management</i> ), takimi jak procesory, pamięci, urządzenia zewnętrzne, sieci. Rozproszone systemy operacyjne mogą próbować zarządzać wszystkimi zasobami systemu rozproszonego globalnie – są to systemy ściśle powiązane. Systemy luźno powiązane to w zasadzie zbiór komputerów z lokalnymi systemami operacyjnymi, które ze sobą współpracują. Systemy ściśle powiązane projektowane są do obsługi wieloprocesorów i multikomputerów homogenicznych. Systemy operacyjne dla heterogenicznych systemów multikomputerowych określane są często jako <b>sieciowe</b> <b>systemy</b> <b>operacyjne</b> (ang. <i>network</i> <i>operating</i> <i>system</i> ). Rozbudowa sieciowego systemu operacyjnego w celu osiągnięcia lepszej przezroczystości zasobów prowadzi do utworzenia <b>oprogramowania</b> <b>warstwy</b> <b>pośredniej</b> (ang. <i>middleware</i> ).<br>
          <br>
          <br>
          <b style=COLOR:#3d85c6><font size=3>Systemy operacyjne dla systemów rozproszonych</font></b><br>
          <hr size=2>
        </div>
        <br>
      </div>
      <div id=zv6e style=TEXT-ALIGN:left>
        <img src="images/dcjpvv6n_2231dkzgbfd5_b.png" style=HEIGHT:339px;WIDTH:500px><br>
        <br>
        <br>
        <b style=COLOR:#3d85c6><font size=3>Struktury wielokomputerowego systemu operacyjnego</font></b><br>
        <hr size=2><br>
        <div id=b_sy style=TEXT-ALIGN:left>
          <img src="images/dcjpvv6n_2232g7dh8rhq_b.png" style=HEIGHT:339px;WIDTH:500px><br>
          <br>
          System operacyjny dla multikomputera składa się z lokalnych systemów operacyjnych, które mają własne jądro, zawierające moduły zarządzania lokalnymi zasobami. Każdy węzeł ma również moduł komunikacyjny umożliwiający wysyłanie i odbiór komunikatów do innych węzłów. Powyżej każdego jądra znajduje się warstwa oprogramowania, która dostarcza dla aplikacji rozproszonych <i>maszyny</i> <i>wirtualnej</i> umożliwiającej równoległe i współbieżne wykonywanie zadań. Warstwa ta może również dostarczać programowej implementacji pamięci dzielonej. Inne zadania tej warstwy to: szeregowanie zadań, maskowanie awarii, zapewnianie przezroczystości pamięci.<br>
          <br>
          <br>
          <b style=COLOR:#3d85c6><font size=3>Wymiana plików</font></b><br>
          <hr size=2><br>
          <div id=mj9j style=TEXT-ALIGN:left>
            <img src="images/dcjpvv6n_2233f2rgs6hc_b.png" style=HEIGHT:341px;WIDTH:500px><br>
            <br>
          </div>
          Systemy wielokomputerowe nie oferujące pamięci dzielonej udostępniają jedynie wymianę komunikatów. Mechanizm wymiany komunikatów wykorzystuje wewnętrznie buforowanie i wprowadza niekiedy blokowanie poszczególnych operacji. Buforowanie może być realizowane zarówno po stronie nadawczej jak i odbiorczej. Blokowanie nadawcy (punkt S1) może się zdarzyć, gdy bufor nadawczy jest przepełniony. Jeżeli bufora nadawczego nie ma, nadawca nadal może być blokowany do czasu faktycznego wysłania komunikatu (punkt S2). Blokowanie może być rozciągnięte w czasie do momentu przybycia komunikatu do odbiorcy (punkt S3) lub do momentu dostarczenia komunikatu (punkt S4). Blokowanie nadawcy do momentu przybycia komunikatu do odbiorcy w praktyce oznacza zagwarantowanie <b>niezawodnej</b> komunikacji (nadawca dowiaduje się, że komunikat dotarł).<br>
          <br>
        </div>
        <br>
        <b style=COLOR:#3d85c6><font size=3>Rozproszona pamięć dzielona</font></b><br>
        <hr size=2><br>
      </div>
      <div id=yz5t style=TEXT-ALIGN:left>
        <img src="images/dcjpvv6n_2234fwvc878k_b.png" style=HEIGHT:340px;WIDTH:500px><br>
        <br>
        Jedną z form komunikacji pomiędzy procesami w systemie rozproszonym jest zastosowanie pamięci dzielonej. W przypadku multikomputerów jest to możliwe poprzez emulowanie działania takiej pamięci. Celem jest utworzenie wirtualnej pamięci, rozproszonej pomiędzy wieloma komputerami, która umożliwi tworzenie aplikacji dla takiego systemu rozproszonego analogicznie jak dla wieloprocesorów. Efekt pamięci dzielonej uzyskuje się poprzez podział wirtualnej przestrzeni adresowej na strony, których lokalizacje rozrzucone są po wszystkich komputerach. Odwołanie do strony nieobecnej lokalnie powoduje wystąpienie pułapki i sprowadzenie strony z węzła posiadającego odpowiednie dane. Idea jest więc taka sama jak w przypadku stronicowania, z tym że zamiast lokalnego dysku jako pamięci pomocniczej wykorzystywana jest zdalna pamięć RAM.<br>
        <br>
        <p>
          Efektywne zagospodarowanie koncepcji rozproszonej pamięci dzielonej napotyka jednak na poważne problemy, związane głównie z efektywnością pracy takiego systemu. Sprowadzenie strony jest operacją bardzo kosztowną, stąd tworzy się lokalne kopie stron, które nie są modyfikowane. Zwielokrotnianie stron modyfikowanych może prowadzić do powstania niespójności poszczególnych kopii, niespójności, które będą utrudniały pracę programiście, komplikując pierwotnie prosty interfejs. Oddzielną kwestią jest problem doboru wielkości strony. Duże strony optymalizują kwestie komunikacji, ale mogą prowadzić do nasilonego zjawiska <b>fałszywego</b> <b>dzielenia</b> . Zjawisko to pojawia się gdy dwa procesy odwołują się do różnych zmiennych, ale ulokowanych na tej samej stronie, co powoduje niepotrzebne przesyłanie zawartości tej strony w celu przeprowadzenia aktualizacji.
        </p>
        <br>
        <br>
        <b style=COLOR:#3d85c6><font size=3>Sieciowy system operacyjny</font></b><br>
        <hr size=2><br>
      </div>
      <div id=lysk style=TEXT-ALIGN:left>
        <img src="images/dcjpvv6n_2235hkjbtdf4_b.png" style=HEIGHT:342px;WIDTH:500px><br>
        <br>
      </div>
      Sieciowe systemy operacyjne nie stawiają sobie tak ambitnych celów jak rozproszone systemy operacyjne. System nie musi wyglądać jakby był całością. Zakłada się, że poszczególne węzły są obsługiwane przez lokalne systemy operacyjne, które udostępniają użytkownikom zbiór usług sieciowych. Systemy wchodzące w skład całego systemu rozproszonego nie muszą być jednorodne. Użytkownicy są świadomi istnienia poszczególnych maszyn w systemie i mogą wykonywać swoje zadania wskazując na system, który ma tego dokonać.<br>
      <br>
      <p>
        Sieciowe systemy operacyjne stawiają większe wymagania użytkownikom, gdyż użytkownicy są świadomi rozproszenia i są zmuszeni do posługiwania się systemem w nieco inny sposób. Ponieważ systemy wchodzące w skład sieciowego systemu są autonomiczne, zarządzanie nimi też musi być realizowane osobno, co jest dodatkowym utrudnieniem dla administratora i użytkowników (np. zmiana hasła musi być realizowana oddzielnie na każdym z serwerów).
      </p>
      <br>
      <br>
      <b style=COLOR:#3d85c6><font size=3>Usługi sieciowego systemu operacyjnego</font></b><br>
      <hr size=2><br>
      <div id=uja: style=TEXT-ALIGN:left>
        <img src="images/dcjpvv6n_2236dt2fx4d5_b.png" style=HEIGHT:340px;WIDTH:500px>
      </div>
      <br>
      Typowe usługi sieciowych systemów operacyjnych to:<br>
      <br>
      <ul>
        <li>
          zdalne logowanie (np. realizowane komendą <i>rlogin</i> )
        </li>
        <li>
          kopiowanie plików pomiędzy systemami (np. <i>rcp</i> )
        </li>
        <li>
          sieciowe systemy plików (serwery plików i klienci)
        </li>
      </ul>
      <br>
      <p>
        Sieciowe systemy plików są bardzo wygodne w użyciu gdyż przypominają lokalne systemy plików. Różni klienci mogą mieć różny obraz zawartości pojedynczego serwera plików w zależności od lokalnego systemu operacyjnego.
      </p>
      <br>
      <br>
      <b style=COLOR:#3d85c6><font size=3>Oprogramowanie warstwy pośredniej</font></b><br>
      <hr size=2><br>
      <div id=tlry style=TEXT-ALIGN:left>
        <img src="images/dcjpvv6n_2237k8nh22t4_b.png" style=HEIGHT:340px;WIDTH:500px><br>
        <br>
        Rozproszony system operacyjny służy do obsługi multikomputerów, a więc komputerów ściśle ze sobą powiązanych. Sieciowy system operacyjny nie oferuje z kolei przezroczystości rozproszonego systemu operacyjnego. Uzyskanie systemu rozproszonego zgodnego z podaną wcześniej definicją wymaga wprowadzenia dodatkowej warstwy oprogramowania; warstwy pośredniej (ang. <i>middleware</i> ), nadbudowującej nad usługami sieciowymi usługi dla systemu rozproszonego. W zakresie komunikacji np. sieciowe systemy operacyjne oferują interfejs gniazd (ang. <i>sockets</i> ), umożliwiający komunikację pomiędzy rozproszonymi procesami, ale wymagający wskazania lokalizacji poszczególnych procesów (np. poprzez adresy IP). W systemie rozproszonym warstwa pośrednia może dostarczać mechanizmów transparentnej komunikacji, w które procesy identyfikowane są w sposób abstrakcyjny, niezależny od lokalizacji (potencjalnie zmiennej) procesów.<br>
        <br>
        <p>
          Zadania warstwy pośredniej dotyczą integracji systemów, które ze swojej strony są autonomiczne. Oznacza to, że zarządzanie zasobami lokalnymi jest powierzone lokalnemu systemowi operacyjnemu. Warstwa pośrednia nadbudowuje na tej bazie nowe usługi.<br>
        </p>
        <p>
          <br>
        </p>
        <p>
          Warstwa pośrednia powinna ukrywać fakt heterogeniczności systemów składowych. Dzieje się to poprzez definicje nowych interfejsów komunikacyjnych, niezależnych od interfejsów lokalnych systemów operacyjnych. Aplikacje rozproszone powinny posługiwać się tylko tymi interfejsami i nie powinny korzystać bezpośrednio z usług lokalnego systemu operacyjnego.<br>
        </p>
        <p>
          <br>
        </p>
        <p>
          <br>
        </p>
        <p>
          <b style=COLOR:#3d85c6><font size=3>Paradygmaty warstwy pośredniej</font></b><br>
        </p>
        <hr size=2><br>
        <div id=x5cg style=TEXT-ALIGN:left>
          <img src="images/dcjpvv6n_2238vbsn36fk_b.png" style=HEIGHT:341px;WIDTH:500px>
        </div>
        <br>
        Oprogramowanie warstwy pośredniej tworzone jest bardzo często wokół pewnych <i>paradygmatów</i> , a więc wzorców, do których dopasowuje się rożne fragmenty systemu. Jednym z nich jest traktowanie wszystkiego jako pliki – podobnie jak to ma miejsce w systemie Unix. Przy takim podejściu komunikacja staje się równoważna zapisowi do pliku, ponieważ pliki są widziane przez wszystkie procesy w taki sam sposób. Pewnym ograniczeniem tej koncepcji jest rozproszony system plików, gdzie transparentność dotyczy jedynie klasycznie rozumianych plików.<br>
        <br>
        <p>
          Innym podejściem jest koncepcja <b>zdalnych</b> <b>wywołań</b> <b>procedur</b> , gdzie główny nacisk położono na ukrywanie faktu komunikacji sieciowej. Wysłanie komunikatu do serwera i odbiór odpowiedzi jest traktowane jako wywołanie metody, co czyni tą koncepcję zbliżoną do programowania w systemach scentralizowanych (lokalne wywołanie procedury).<br>
        </p>
        <p>
          <br>
        </p>
        <p>
          Pewną rozbudową koncepcji zdalnych wywołań procedur są obiekty rozproszone. Obiekty takie najczęściej są uruchamiane fizycznie na jednej maszynie, ale dostęp do nich jest możliwy w sposób transparentny z wielu innych maszyn. Jest to możliwe poprzez udostępnienie interfejsów do obiektów rozproszonych. Wywołanie metody obiektu powoduje tu również przesłanie komunikatu do i z serwera i zdalne wykonanie przetwarzania.<br>
        </p>
        <p>
          <br>
        </p>
        <p>
          Popularność usługi WWW może być przykładem jak skrajne uproszczenie interfejsu i koncepcji może przyczynić się do upowszechnienia usługi. Dokumenty (nie tylko tekstowe) zawierają odnośniki do innych dokumentów tworząc w ten sposób ogólnoświatową sieć połączeń. Adres dokumentu jest w zasadzie jego identyfikatorem, nie wskazującym bezpośrednio na jego lokalizację.
        </p>
        <br>
        <br>
        <b style=COLOR:#3d85c6><font size=3>Usługi warstwy pośredniej</font></b><br>
        <hr size=2><br>
        <div id=tdjh style=TEXT-ALIGN:left>
          <img src="images/dcjpvv6n_22396n24ckd2_b.png" style=HEIGHT:340px;WIDTH:500px><br>
          <br>
        </div>
        Jedną z podstawowych usług warstwy pośredniej jest <b>komunikacja</b> , ukrywająca fakt rozproszenia poszczególnych maszyn. Może być realizowana z wykorzystaniem wspomnianych wcześniej zdalnych wywołań procedur, obiektów rozproszonych lub poprzez transparentny dostęp do danych (plików czy baz danych). Dostęp do rozproszonych dokumentów WWW może być też traktowany jako jednokierunkowa forma komunikacji serwer?użytkownik.<br>
        <br>
        <p>
          Kolejną ważną usługą warstwy pośredniej jest <b>usługa</b> <b>nazewnicza</b> , umożliwiająca publikowanie i wyszukiwanie informacji. Trudności w implementacji tej usługi wiążą się głównie z koniecznością zapewnienia jej wysokiej skalowalności. Czas dostępu do informacji, a więc np. odwzorowania identyfikatora na poszukiwany obiekt, powinien być praktycznie niezależny od wielkości systemu.<br>
        </p>
        <p>
          <br>
        </p>
        <p>
          Z punktu widzenia aplikacji biznesowych istotną usługą jest możliwość zapewniania <b>trwałości</b> generowanym przez aplikację danych. Usługa ta jest oferowana w sposób naturalny w przypadku rozproszonych systemów plików czy rozproszonych baz danych, ale może też występować niezależnie jako element innych usług, np. rozproszonej pamięci dzielonej.<br>
        </p>
        <p>
          <br>
        </p>
        <p>
          Przetwarzanie danych w systemach rozproszonych może wymagać stosowania <b>rozproszonych</b> <b>transakcji</b> . Jedną z własności transakcji jest atomowość, gwarantująca wykonanie wszystkich operacji składowych transakcji w sposób niepodzielny. Atomowa realizacja zbioru operacji modyfikujących na wielu różnych serwerach, które dodatkowo mogą ulegać awarii, jest zadaniem bardzo trudnym, a często wręcz niemożliwym do zrealizowania. Transakcje rozproszone generują również problemy związane ze skalowalnością.<br>
        </p>
        <p>
          <br>
        </p>
        <p>
          <i>Last</i> <i>but</i> <i>not</i> <i>least</i> – czyli problem <b>bezpieczeństwa</b> , który jest często pomijany w prototypowych implementacjach, a który jest niezwykle istotny z praktycznego punktu widzenia. System rozproszony nie może polegać na mechanizmach bezpieczeństwa oferowanych i zarządzanych przez lokalne systemy operacyjne. Współpraca tych systemów wymaga, aby mechanizmy zapewniające bezpieczeństwo były realizowane od nowa i w sposób kompleksowy w warstwie pośredniej.
        </p>
        <br>
        <a href=http://wazniak.mimuw.edu.pl/index.php?title=Sr-1-wyk-1.0-Slajd27 title=Sr-1-wyk-1.0-Slajd27> </a><br>
        <b style=COLOR:#3d85c6><font size=3>Otwartość warstwy pośredniej</font></b><br>
        <hr size=2><br>
      </div>
      <div id=kzyh style=TEXT-ALIGN:left>
        <img src="images/dcjpvv6n_2240dm7fgq5t_b.png" style=HEIGHT:341px;WIDTH:500px><br>
        <p>
          <br>
          Oprogramowanie warstwy pośredniej jest budowane najczęściej dla pewnego zbioru systemów operacyjnych, a więc jego zastosowanie powinno nas uniezależnić od systemu operacyjnego. W praktyce jednak aplikacje muszą wykorzystywać interfejsy warstwy pośredniej, co powoduje powstanie zależności od tej warstwy. Nawet jeżeli interfejsy warstwy pośredniej zostały ustandaryzowane, nie daje to gwarancji przenośności aplikacji między różnymi implementacjami tego standardu. Wynika to z jednej strony z niekompletności interfejsów, powodujących konieczność odwoływania się bezpośrednio do systemu operacyjnego, a z drugiej strony z niezgodności zastosowanych protokołów (pomimo zgodności interfejsów).
        </p>
        <br>
        <a href=http://wazniak.mimuw.edu.pl/index.php?title=Sr-1-wyk-1.0-Slajd28 title=Sr-1-wyk-1.0-Slajd28> </a><br>
        <b style=COLOR:#3d85c6><font size=3>Porównanie systemów</font></b><br>
        <hr size=2><br>
        <div id=l1o1 style=TEXT-ALIGN:left>
          <img src="images/dcjpvv6n_2241hr4dwggt_b.png" style=HEIGHT:340px;WIDTH:500px><br>
          <br>
          <p>
            Przedstawione w tabeli klasy systemów operacyjnych pokazują, że w praktyce nie ma systemów idealnych, a więc takich, które jednocześnie oferowałyby wysoką przezroczystość, były otwarte, wysoko wydajne i oferowały dobrą skalowalność. Systemy wieloprocesorowe nie są otwarte, ale za to bardzo efektywne, bo ten właśnie aspekt jest w nich najważniejszy. Sieciowe systemy operacyjne są otwarte i skalowalne, ale stosowane w nich mechanizmy komunikacyjne nie są zbyt wygodne i nie oferują one zadowalającej przezroczystości. Systemy oparte na warstwie pośredniej oferują dużą przezroczystość, ale kosztem jest tu ograniczona skalowalność.
          </p>
          <br>
          <br>
          <b style=COLOR:#3d85c6><font size=3>Rozproszenie procesów</font></b><br>
          <hr size=2><br>
          <div id=yy3t style=TEXT-ALIGN:left>
            <img src="images/dcjpvv6n_2242cxprdwjf_b.png" style=HEIGHT:339px;WIDTH:500px><br>
            <br>
            Organizację systemu rozproszonego można opisywać na wiele sposobów. Jednym z nich jest wyróżnienie procesów, czy funkcji pełnionych przez określone procesy, poprzez wskazanie na serwery i klientów. Serwer jest procesem usługowym, udostępniającym określoną funkcjonalność. Klient zleca wykonanie akcji serwerowi. Funkcje klientów i serwerów mogą się nakładać na siebie. Schemat interakcji klient-serwer (przedstawiony na rysunku) opisywany jest jako zachowanie żądanie-odpowiedź (ang. <i>request-reply</i> <i>behaviour</i>).<br>
            <br>
            <p>
              Komunikacja pomiędzy klientem a serwerem może być realizowana z wykorzystanie protokołu bezpołączeniowego jak i połączeniowego. W pierwszym przypadku zyskujemy na efektywności przetwarzania (nie trzeba nawiązywać połączenia), ale trzeba uwzględnić możliwość utraty komunikatu w sieci. Co więcej: klient nie jest w stanie rozróżnić sytuacji zaginięcia komunikatu z żądaniem od zaginięcia komunikatu z odpowiedzią. W efekcie, powtarzając żądanie wykonania zdalnej usługi, może dojść do powielonego wykonania tych samych działań, co nie zawsze będzie akceptowalne.
            </p>
            <br>
            <br>
            <b style=COLOR:#3d85c6><font size=3>Warstwy aplikacji</font></b><br>
            <hr size=2><br>
          </div>
          <div id=v4pk style=TEXT-ALIGN:left>
            <img src="images/dcjpvv6n_2243gfxjcjgm_b.png" style=HEIGHT:341px;WIDTH:500px><br>
            <br>
            <p>
              Opisywanie aplikacji poprzez rozróżnianie funkcji serwera i klienta jest niekiedy niewygodne i nieodpowiednie. Bardziej adekwatny jest podział warstwowy aplikacji, wskazujący na funkcje poszczególnych modułów. Najczęściej spotykanym podejściem jest wyróżnienie w aplikacji wielu warstw odpowiedzialnych za różne poziomy przetwarzania: poziom interfejsu użytkownika, poziom przetwarzania i poziom danych.<br>
            </p>
            <p>
              <br>
            </p>
            <p>
              <b>Poziom</b> <b>interfejsu</b> <b>użytkownika</b> najczęściej jest częścią aplikacji-klienta, zawierając wszystko co jest niezbędne do przeprowadzenia bezpośredniej interakcji z użytkownikiem. Stopień skomplikowania interfejsu użytkownika może być bardzo różny: od prostego ekranu znakowego, poprzez interfejs webowy, aż do złożonego interfejsu graficznego.<br>
            </p>
            <p>
              <br>
            </p>
            <p>
              <b>Poziom</b> <b>przetwarzania</b> to właściwa część aplikacji, zawierająca implementację określonego przetwarzania. Zakres działań wykonywanych przez tą warstwę może być bardzo różny i zależny od konkretnej aplikacji.<br>
            </p>
            <p>
              <br>
            </p>
            <p>
              <b>Poziom</b> <b>danych</b> ma zapewnić przede wszystkim trwałość przechowywanych danych, oznaczająca możliwość dostępu do tych samych danych po wyłączeniu i włączeniu aplikacji. W najprostszej realizacji poziom danych może być zrealizowany w postaci plików, ale częściej stosowana jest do tego celu baza danych. Baza danych dodatkowo gwarantuje spójność danych pomiędzy wieloma aplikacjami. Dotyczy to zarówno schematu danych, jak i współbieżnego ich przetwarzania. Bazy danych mogą być zarówno typu relacyjnego (zastosowania biznesowe), jak i obiektowego (projektowanie wspomagane komputerowo, multimedia).<br>
            </p>
            <p>
              <br>
            </p>
            <p>
              Przykład: wyszukiwarka internetowa. Interfejsem użytkownika w tym przypadku jest dokument HTML wyświetlany w przeglądarce. Po wysłaniu żądania do serwera następuje jego przetwarzanie, polegające na interpretacji zapytania, wyszukaniu surowych odpowiedzi, ich poklasyfikowaniu i przygotowaniu odpowiedzi w postaci odpowiedniego dokumentu HTML. Realizacja zapytania wymaga w tym przypadku sięgnięcia do bazy danych przechowującej indeks zawartości stron WWW w Internecie.
            </p>
            <br>
            <br>
            <b style=COLOR:#3d85c6><font size=3>Architektura wielowarstwowa</font></b><br>
            <hr size=2><br>
          </div>
          <div id=oj_s style=TEXT-ALIGN:left>
            <img src="images/dcjpvv6n_2244g3r2nbdd_b.png" style=HEIGHT:342px;WIDTH:500px><br>
            <br>
            Serwery bardzo często pełnią rolę klientów odwołując się do innych usług. Można więc rozpatrywać budowę złożonego systemu rozproszonego jako architekturę wielowarstwową. Bardzo popularny jest model trójwarstwowy, w którym wyróżnia się <b>serwer</b> <b>aplikacji</b> implementujący logikę aplikacji i <b>serwer</b> <b>baz</b> <b>danych</b> zajmujący się już tylko składowaniem danych. Serwer aplikacji w takim modelu jest klientem serwera baz danych. Użytkownicy końcowi natomiast kierują swoje żądania tylko do serwera aplikacji. Wydzielenie serwera baz danych potencjalnie pozwala na jego podmianę bez konieczności zmiany kodu w aplikacjach klienckich.
            <p>
              <br>
            </p>
            <p>
              Poszczególne warstwy oprogramowania architektury wielowarstwowej mogą być instalowane i uruchamiane na różnych komputerach, co jest naturalnym przejściem do systemów rozproszonych. Mówi się tu o <b>rozproszeniu</b> <b>pionowym</b> (ang. <i>vertical</i> <i>distribution</i> ). W praktyce jednak znacznie istotniejsze jest <b>rozproszenie</b> <b>poziome</b> (ang. <i>horizontal</i> <i>distribution</i> ), które oznacza, że rozproszeniu podlegają części składowe poszczególnych warstw. W przypadku baz danych np. może oznaczać to rozmieszczenie części danych na różnych serwerach. W efekcie uzyskujemy możliwość współbieżnego przetwarzania danych przez różne serwery, równoważąc w ten sposób obciążenie. Rozproszenie poziome może być też realizowane w formie zwielokrotnienia tych samych danych (usług) na wielu serwerach.<br>
            </p>
            <p>
              <br>
            </p>
            <p>
              Rozproszenie może również dotyczyć klientów. W przypadku prostych aplikacji współpraca klientów może nawet nie wymagać obecności serwera lub jego funkcje zostaną ograniczone do lokalizacji pozostałych klientów. Mówimy w tym przypadku o <b>rozproszeniu</b> <b>partnerskim</b> (ang. <i>peer-to-peer</i> <i>distribution</i>).
            </p>
            <br>
            <br>
            <b style=COLOR:#3d85c6><font size=3>Architektury klient-serwer</font></b><br>
            <hr size=2><br>
          </div>
          <div id=kro2 style=TEXT-ALIGN:left>
            <img src="images/dcjpvv6n_2245fsz7hrc9_b.png" style=HEIGHT:342px;WIDTH:500px><br>
            <br>
            Rozróżnienie funkcji klienta i serwera może mieć różne przełożenie na implementację. W przypadku komputerów typu <i>mainframe</i> , gdzie całość przetwarzania odbywa się na centralnym serwerze, zadania klienta sprowadzają się jedynie do prezentacji tego, co wyśle serwer. Mówi się w tym przypadku o tzw. <i>cieńkim</i> <i>kliencie</i> (ang. <i>thin</i> <i>client</i> ). Z drugiej jednak strony duża część przetwarzania może zostać przeniesiona z serwera do klienta celem odciążenia tego pierwszego. W takim przypadku mamy do czynienia z <i>grubym</i> lub <i>bogatym</i> <i>klientem</i> (ang. <i>fat/rich</i> <i>client</i> ). Można też rozważać różne rozwiązania pośrednie. Na przedstawionym powyżej rysunku skrajnie po lewej mamy np. architekturę terminalową, gdzie klient realizuje tylko część interfejsu użytkownika (a). W przypadku (b) klient obsługuje w całości interfejs z użytkownikiem. Jeżeli część przetwarzania jest realizowana po stronie klienta, to dostajemy realizację z rys. (c). Przykładem takiej organizacji jest formularz HTML z kodem JavaScript dokonującym wstępnej weryfikacji danych wprowadzanych w przeglądarce. Aplikacja może realizować swoje zadania całkowicie po stronie klienta odwołując się tylko do bazy danych po stronie serwera (d). Przykładem takiej organizacji może być aplet Java pracujący w przeglądarce. W skrajnym przypadku również część danych może być składowana po stronie klienta realizując schemat z rys. (e). Sytuacja taka może mieć miejsce w przypadku aplikacji mobilnych, które mają łączność z serwerem tylko czasowo.<br>
            <br>
          </div>
          <br>
        </div>
      </div>
    </div>
  </div>
</div>
<br></body>
</html>